1. Field of the Invention
The present invention relates, generally, to operational environment systems and methods for communication network service applications and, more specifically, to an operational environment system and method which allows operators and third parties to implement service ideas directly into a communication network without having to pass through a network supplier and which ensures that faulty service applications implemented in such a way have no negative effects.
2. Description of the Prior Art
In present-day N-ISDN and B-ISDN telecommunications networks, Service Applications are provided as part of the known Intelligent Network (IN for short). FIG. 1 shows the architecture of the Intelligent Network. The Intelligent Network is intended to allow a network operator to introduce new services quickly and without any problems, and without having to take any actions relating to the installation program systems in each network node. Such actions in an IN are therefore limited to as few central network nodes, so-called Service Control Points SCP, as possible. These points, at a central point, are equipped with the appropriate application software for the new services, the so-called Service Applications, after which, by a type of xe2x80x9cremote controlxe2x80x9d, it is possible for the individual network nodes to implement the new services.
The remote-control network nodes of the IN are also called Service Access nodes or Service Switching Points SSP. They are connected to a Service Control Point SCP directly or via a signalling network, such as the CCS7 signalling network. A Service Management Point SMP is used by the network operator, the service provider and the service subscriber to administer the IN services.
A call to a service on the Intelligent Network may first of all be routed to a Service Switching Point SSP from a normal network node, that is to say a network node that is not remotely controlled by the SCP. The Service Switching Point uses the dialed number and/or the Service Code to determine which Service Control Point SCP contains the Service Application corresponding to this Service and then sends a request to this Service Control Point as to how it must process the call. Once the SCP has investigated the request, it sends a reply to the Service Switching Point, which reply contains information that the Service Switching Point requires to continue processing the call.
The Service Control Point SCP requires a hardware/software computer platform that is as fault-free as possible since the Service Applications must have the same high availability as the other components in the basic network (SSP and other switching centers). For this reason, the Service Applications are nowadays developed by the network suppliers"" software specialists and are systematically tested, at high cost. All that the network operator can do is to modify, i.e. customize these Service Applications at the points provided for this purpose. Examples of such Service Applications include:
xe2x80x9cgreenxe2x80x9d numbers (freephone; toll-free numbers)
Virtual Private Network
It would therefore be desirable for Service Applications (in the SCP and, to some extent, in the SMP) to be programmed directly by the network operator or third parties; for example, software houses. In this way, network operators can implement their service ideas directly and without passing via the network suppliers (Open Network Provisioning: ONP). However, this capability involves a risk of the introduction of faulty Service Applications.
Although known fault-tolerant hardware techniques are known (N+1, 1:1 redundancy, microsynchrone systems), it is impossible to prevent serious logic faults when programming software in the way mentioned above, such may lead to the system applications crashing or behaving incorrectly in a dynamic situation. This normally causes a reaction on other Service Applications and/or on the basic network.
Examples of such logic faults include:
An event expected by a Service Application never occurs. The operation is blocked (deadlock).
A Service Application goes into an inactive loop (endless loop) in which sensible functions are no longer carried out.
A Service Application periodically carries out a message interchange with the basic network or with other SCP functions, but without carrying out any sensible network function (active loop). There is also a risk of system overload for other Service Applications that are not involved.
Without any countermeasures against this type of logic fault, it is impossible to allow network operators and/or third parties to have access to the SCP/SMP for service programming.
The invention is based on the object of making it possible for network operators and/or third parties, for example, software houses, to implement their service ideas directly and without passing via the network suppliers, and at the same time to ensure that faulty Service Applications implemented in such a way have no negative effects.
In an embodiment of the present invention, an operational environment system on a communication network is disclosed which includes an Application Programming Interface (API) which has function modules accessible by network operators and/or third parties for programming purposes, a Service Application Program (SAP) which is programed into the API via the function modules, and a monitoring system which checks at predetermined times whether the SAP is operating logically correctly and which deactivates the operation of the SAP upon an incorrect operation.
In an embodiment, the operational environment system further includes one or more events transmitted by the communication network to the monitoring system and for which the SAP is waiting in a wait state, storage means in the monitoring system for storing the one or more events, and wherein the monitoring system checks whether the one or more events are logically correct taking account of the wait state of the SAP and thereafter ends the call and/or deactivates the operation of the SAP upon an incorrect operation.
In an embodiment of the operational environment system, the monitoring system checks whether it is to be expected that the communication network will still transmit events and thereafter ends the call and/or deactivates the operation of the SAP upon a finding that no events will be transmitted.
In an embodiment of the operational environment system, the monitoring system checks, if no events have been entered in the storage means, whether a context change has occurred within the SAP since a last check and thereafter ends the call and/or deactivates the operation of the SAP upon finding that no context change has occurred.
In an embodiment of the operational environment system, the monitoring system checks, if a context change has occurred with the SAP since the last check, whether the SAP has carried out at least one message interchange and thereafter ends the call and/or deactivates the operation of the SAP if the check indicates that no message interchange has occurred.
In an embodiment, the operational environment system further includes an event counter, wherein the monitoring system checks whether the event counter has overrun, if at least one message interchange has taken place since the last check, and thereafter ends the call and/or deactivates the operation of the SAP if the check indicates that the event counter has overrun.
In a further embodiment of the present invention, a method of addressing faults in an operational environment system on a communication network is disclosed which includes the steps of: providing an Application Programming Interface (API) in the operational environment system wherein the API includes function modules accessible by network operators and/or third parties; programming a Service Application Program (SAP) into the function module; providing a monitoring system in the operational environment system; using the monitoring system to check at predetermined times whether the SAP is operating logically correctly; and deactivating the operation of the SAP if the SAP is logically incorrect.
In an embodiment, the method further includes the steps of: providing storage means in the monitoring system; placing the SAP in a wait state; transmitting a plurality of events via the communication network with respect to a call to the monitoring system; storing the plurality of events in the storage means; using the monitoring system to check at predetermined times if the SAP is in the wait state and if the plurality of events are logically correct; and ending the call and deactivating the SAP if the plurality of events are logically incorrect.
In an embodiment, the method further includes the steps of: using the monitoring system to check at predetermined times if the SAP is in the wait state and if the SAP is expecting further events to be transmitted via the communication network; and ending the call and deactivating the SAP if no further events are expected by the SAP.
In an embodiment, the method further includes the steps of: using the monitoring system to check at predetermined times if the SAP is in the wait state and if a context change has occurred in the SAP since a previous check; and ending the call and deactivating the SAP if no context change has occurred.
In an embodiment, the method further includes the steps of: using the monitoring system to check if the SAP has carried out at least one message interchange if a context change has occurred; and ending the call and deactivating the SAP if no message interchange has occurred.
In an embodiment, the method further includes the steps of: providing an event counter in the operational environment system; using the monitoring system to check whether the event counter has overrun if at least one message interchange has occurred since the previous check; and ending the call and deactivating the SAP if the event counter has overrun.
Additional features and advantages of the present invention are described in, and will be apparent from, the Detailed Description of the Preferred Embodiments and from the Drawings.